REMARKS 

1. Present Status of Patent Application 

This is a full and timely response to the outstanding final Office Action of 
February 21, 2008. Claims 1, 10, 19, and 24 have been amended, and claims 1,3-11, 
13-19, 21-25, and 27-32 remain pending in the present application. Reconsideration 
and allowance of the application and presently pending claims are respectfully 
requested. 



2. Response to Rejections of Claims 1.3-11, 13-19. 21-22. 24-25, and 27-32 under 
35U.S.C.S103 

Claims 1, 3-11, 13-19, 21-22, 24-25, and 27-32 have been rejected under 35 
U.S.C. §1 03(a) as allegedly being unpatentable over Persels (U.S. Patent No. 
7,065,547) in view of Hashem (U.S. Patent No. 7,155,578). 



a. Claim 1 

As provided in independent claim 1 , Applicant claims: 

A file handling system, comprising: 
a terminating file transfer server operable to receive a file transfer 
message from an originating file transfer server along with at least 
one file, the file transfer message including details about the 
transfer of said at least one file including a local user and at least 
one filename for said at least one file; 

an agent operable to read the file transfer message 
received from the originating file server, and direct the transfer 
of said at least one filename and said at least one file 
associated with said at least one filename to a home directory 
associated with the local user in accordance with instructions 
from a configuration file residing in the home directory; and 

the configuration file residing in the home directory, and 
operable to instruct the agent to transfer said at least one file 
from the home directory to a remote host, wherein the 
configuration file comprises a host name and a port name of 
the remote host thereby allowing transfer of said at least one 
file to the remote host without necessitating a local presence 
of the remote host on the terminating file transfer server. 

(Emphasis added). 
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Applicant respectfully submits that independent claim 1 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"an agent operable to read the file transfer message received from the originating file 
server, and direct the transfer of said at least one filename and said at least one file 
associated with said at least one filename to a home directory associated with the local 
user in accordance with instructions from a configuration file residing in the home 
directory; and the configuration file residing in the home directory, and operable to 
instruct the agent to transfer said at least one file from the home directory to a remote 
host, wherein the configuration file comprises a host name and a port name of the 
remote host thereby allowing transfer of said at least one file to the remote host without 
necessitating a local presence of the remote host on the terminating file transfer server," 
as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "an agent operable to read the file transfer message received 
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from the originating file server, and direct the transfer of said at least one filename and 
said at least one file associated with said at least one filename to a home directory 
associated with the local user in accordance with instructions from a configuration file 
residing in the home directory; and the configuration file residing in the home directory, 
and operable to instruct the agent to transfer said at least one file from the home 
directory to a remote host, wherein the configuration file comprises a host name and a 
port name of the remote host thereby allowing transfer of said at least one file to the 
remote host without necessitating a local presence of the remote host on the 
terminating file transfer server," as recited in claim 1 . 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem requires a host having an internal inbasket to establish a local 
presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "an agent operable to read the file transfer 
message received from the originating file server, and direct the transfer of said at least 
one filename and said at least one file associated with said at least one filename to a 
home directory associated with the local user in accordance with instructions from a 
configuration file residing in the home directory; and the configuration file residing in the 
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home directory, and operable to instruct the agent to transfer said at least one file from 
the home directory to a remote host, wherein the configuration file comprises a host 
name and a port name of the remote host thereby allowing transfer of said at least one 
file to the remote host without necessitating a local presence of the remote host on the 
terminating file transfer server," as recited in claim 1 . For example, neither Persels nor 
Hashem describes that a file received at an inbasket is transferred to a home directory 
in accordance with directions residing at the inbasket by an agent residing at the 
inbasket. For example, Hashem describes that a remote process downloads a file 
found in an external inbasket. 

Accordingly, claim 1 is patentable over Persels in view of Hashem, and the 
rejection of claim 1 should be withdrawn. 



b. Claims 3-9 

For at least the reasons given above, claim 1 is allowable over the cited art of 
record. Since claims 3-9 depend from and include the features of claim 1 and recite 
additional features, claims 3-9 are allowable as a matter of law over the cited art of record. 

c. Claim 10 

As provided in independent claim 10, Applicant claims: 

A method of handling files on a Connect: Direct server, comprising: 
receiving a file transfer message from an originating file transfer 

server; 

determining a home directory from a local user associated with the 
file transfer message; 

storing at least one file associated with the file transfer message in 
the home directory; 

retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a 
remote host; and 

transmitting said at least one file responsive to the 
configuration file to the remote host without necessitating a local 
presence of the remote host 

(Emphasis added). 
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Applicant respectfully submits that independent claim 10 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"retrieving a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting said at least 
one file responsive to the configuration file to the remote host without necessitating a 
local presence of the remote host," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a remote host; and 
transmitting said at least one file responsive to the configuration file to the remote host 
without necessitating a local presence of the remote host," as recited in claim 10. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
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location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem requires a host having an internal inbasket to establish a local 
presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "retrieving a configuration file from the home 
directory, wherein the configuration file comprises a host name and a port name of a 
remote host; and transmitting said at least one file responsive to the configuration file to 
the remote host without necessitating a local presence of the remote host," as recited in 
claim 10. For example, neither Persels nor Hashem describes that a file received at an 
inbasket is transferred to a home directory in accordance with directions residing at the 
inbasket by an agent residing at the inbasket. For example, Hashem describes that a 
remote process downloads a file found in an external inbasket. 

Accordingly, claim 10 is patentable over Persels in view of Hashem, and the 
rejection of claim 10 should be withdrawn. 

d. Claims 11 and 13-18 

For at least the reasons given above, claim 10 is allowable over the cited art of 
record. Since claims 11 and 13-18 depend from and include the features of claim 10 and 
recite additional features, claims 11 and 13-18 are allowable as a matter of law over the 
cited art of record. 
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e. Claim 19 

As provided in independent claim 19, Applicant claims: 

A Connect: Direct file handling system, comprising: 

a terminating file transfer server; 

an agent; and 

a configuration file; 

the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer 
message comprising a local username and at least one filename, and 
the agent being operable to direct the transfer of at least one file 
associated with the filename to a home directory associated with the 
username, the agent being further operable to read the configuration 
file, and transfer said at least one file to a remote host specified by 
the configuration file without necessitating a local presence of the 
remote host on the terminating file server, wherein the configuration 
file is operable to store a host name and a port number associated 
with the remote host. 

(Emphasis added). 

Applicant respectfully submits that independent claim 19 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server being operable to launch the agent upon receipt of a 
file transfer message, the file transfer message comprising a local username and at 
least one filename, and the agent being operable to direct the transfer of at least one file 
associated with the filename to a home directory associated with the username, the 
agent being further operable to read the configuration file, and transfer said at least one 
file to a remote host specified by the configuration file without necessitating a local 
presence of the remote host on the terminating file server, wherein the configuration file 
is operable to store a host name and a port number associated with the remote host," 
as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
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message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer message comprising a 
local username and at least one filename, and the agent being operable to direct the 
transfer of at least one file associated with the filename to a home directory associated 
with the username, the agent being further operable to read the configuration file, and 
transfer said at least one file to a remote host specified by the configuration file without 
necessitating a local presence of the remote host on the terminating file server, wherein 
the configuration file is operable to store a host name and a port number associated 
with the remote host," as recited in claim 19. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
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may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem requires a host having an internal inbasket to establish a local 
presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "the terminating file transfer server being 
operable to launch the agent upon receipt of a file transfer message, the file transfer 
message comprising a local username and at least one filename, and the agent being 
operable to direct the transfer of at least one file associated with the filename to a home 
directory associated with the username, the agent being further operable to read the 
configuration file, and transfer said at least one file to a remote host specified by the 
configuration file without necessitating a local presence of the remote host on the 
terminating file server, wherein the configuration file is operable to store a host name 
and a port number associated with the remote host," as recited in claim 19. For 
example, neither Persels nor Hashem describes that a file received at an inbasket is 
transferred to a home directory in accordance with directions residing at the inbasket by 
an agent residing at the inbasket. For example, Hashem describes that a remote 
process downloads a file found in an external inbasket. 

Accordingly, claim 19 is patentable over Persels in view of Hashem, and the 
rejection of claim 19 should be withdrawn. 

f. Claims 21-22 

For at least the reasons given above, claim 19 is allowable over the cited art of 
record. Since claims 21-22 depend from and include the features of claim 19 and recite 
additional features, claims 21-22 are allowable as a matter of law over the cited art of 
record. 
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g. Claim 24 

As provided in independent claim 24, Applicant claims: 

A computer readable storage medium having a program for 
handling files on a Connect: Direct server, wherein the computer readable 
storage medium is a physical structure and the program is operable, when 
executed by a computer to perform: 

receiving a file transfer message from an originating file transfer 

server; 

determining a home directory from a local user associated with the 
file transfer message; 

storing at least one file associated with the file transfer message in 
the home directory; 

retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a 
remote host; and 

transmitting said at least one file responsive to the 
configuration file to the remote host without necessitating a local 
presence of the remote host. 

(Emphasis added). 

Applicant respectfully submits that independent claim 24 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"retrieving a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting said at least 
one file responsive to the configuration file," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 



16 



previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n\ is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a remote host; and 
transmitting said at least one file responsive to the configuration file to the remote host 
without necessitating a local presence of the remote host," as recited in claim 24. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem describes techniques for transferring files from a first location to a 
second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
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inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Accordingly, Hashem requires a host having an internal inbasket to establish a 
local presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "retrieving a configuration file from the home 
directory, wherein the configuration file comprises a host name and a port name of a 
remote host; and transmitting said at least one file responsive to the configuration file to 
the remote host without necessitating a local presence of the remote host," as recited in 
claim 10. For example, neither Persels nor Hashem describes that a file received at an 
inbasket is transferred to a home directory in accordance with directions residing at the 
inbasket by an agent residing at the inbasket. For example, Hashem describes that a 
remote process downloads a file found in an external inbasket. 

Accordingly, claim 24 is patentable over Persels in view of Hashem, and the 
rejection of claim 24 should be withdrawn. 

h. Claims 26-32 

For at least the reasons given above, claim 24 is allowable over the cited art of 
record. Since claims 25 and 27-32 depend from and include the features of claim 24 and 
recite additional features, claims 25 and 27-32 are allowable as a matter of law over the 
cited art of record. 
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3. Response to Rejection of Claim 23 under 35 U.S.C. §103 

Claim 23 has been rejected under 35 U.S.C. §1 03(a) as allegedly being 
unpatentable over Persels in view of Hashem in view of "what was well known in the 
networking art." Applicant respectfully traverses this finding. 

Per MPEP 2144.03(A), "It would not be appropriate for the examiner to take 
official notice of facts without citing a prior art reference where the facts asserted to be 
well known are not capable of instant and unquestionable demonstration as being well- 
known ." (Emphasis added). Also, per MPEP 2144.03(B), "If such notice is taken, the 
basis for such reasoning must be set forth explicitly. The Examiner must provide 
specific factual findings predicated on sound technical and scientific reasoning to 
support his or her conclusion of common knowledge." 

As specific factual findings predicated on sound technical and scientific 
reasoning in support of the conclusion of common knowledge are not provided in the 
Office Action, the rejections based upon this finding should be withdrawn. Further, 
under 37 CFR § 1.104(d)(2), if the rejections are based on facts within the personal 
knowledge of the examiner, "the data should be stated as specifically as possible, and 
the facts must be supported, when called for by the applicant, by an affidavit from the 
examiner. Such an affidavit is subject to contradiction or explanation by the affidavits of 
the applicant and other persons." Therefore, if this rejection is maintained, Applicant 
respectfully requests that document(s) be provided as support. 

Notwithstanding the above traversal, all of the claimed features of independent 
claim 19 are not taught and suggested by Persels and Hashem, as previously discussed. 
Since claim 23 depends from claim 19 and recites additional features, claim 23 is 
allowable as a matter of law over the cited art. 
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CONCLUSION 

Any other statements in the Office Action that are not explicitly addressed herein 
are not intended to be admitted. In addition, any and all findings of inherency are 
traversed as not having been shown to be necessarily present. Furthermore, any and all 
findings of well-known art and official notice, or statements interpreted similarly, should 
not be considered well known for at least the specific and particular reason that the 
Office Action does not include specific factual findings predicated on sound technical 
and scientific reasoning to support such conclusions. 

For at least the reasons set forth above, Applicant respectfully submits that all 
objections and/or rejections have been traversed, rendered moot, and/or 
accommodated, and that the pending claims are in condition for allowance. Favorable 
reconsideration and allowance of the present application and all pending claims are 
hereby courteously requested. In addition, Applicant reserves the right to address any 
comments made in the Office Action that were not specifically addressed herein. Thus, 
such comments should not be deemed admitted by the Applicant. If, in the opinion of 
the Examiner, a telephonic conference would expedite the examination of this matter, the 
Examiner is invited to call the undersigned agent at (770) 933-9500. 

Respectfully submitted, 

/CWG/ 

Charles W. Griggers, Reg. No. 47,283 

THOMAS, KAYDEN, 
HORSTEMEYER & RISLEY, LLP. 

Suite 1500 

600 Galleria Parkway 
Atlanta, Georgia 30339 
(770) 933-9500 
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